Buffer Management for Video Data Telemetry

ABSTRACT

In a system for video data capture and sharing client devices may include one or more video cameras and sensors to capture video data and a local buffer memory for storing the captured video data. The system uses inputs from various sources, including sensors, to determine an operating mode. Based on the operating mode, video recording settings are set for the video cameras to change the size of the video data that is generated and stored in the local buffer memory to optimize its use. When the operating mode corresponds to an event of interest, the data recorded is larger, with higher video quality parameters, and when the operational mode corresponds to video footage of no interest, the data recorded is smaller, with lower video quality parameters. Additionally, other actions can be taken based on the operational mode, such as over-write the video recording parameters, notify users of likely loss of recorded data, and the like.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a divisional of and claims priority to PCT PatentApplication No. PCT/US17/50991, entitled “Video-Based Data Collection,Image Capture and Analysis Configuration,” filed Sep. 11, 2017, whichclaims the benefit of U.S. Provisional Application No. 62/412,764, filedOct. 25, 2016, the contents of which are hereby incorporated byreference in their entirety.

BACKGROUND OF THE INVENTION

This disclosure generally relates to video-based data collectionsystems, and more specifically to an image, video, and sensor datacapture, storage, transmission, and analysis.

With the wide adoption of smartphones and our ubiquitous connectivity tothe Internet and social networks, software apps and cameras have becomecommon place in our daily lives for personal applications. We takepictures and videos with our smartphones of all sorts of events, items,and situations, and easily upload to cloud services and share them withfriends, family, and other people who subscribe or follow our sharedcontent.

Many products and services also exist in the smart home or automatedhome market segment. Security cameras around the home or business placeare widely used that record either constantly or with event-basedtriggers, like motion sensors, and store the recorded video locally onvideo servers or upload the video to cloud services, either via wiredconnections through a home router or using Wi-Fi to connect to a homenetwork. The recorded video is typically available for the user for aperiod of time and accessible in real time from software apps insmartphones or via websites. Multi-camera systems store video feeds fromvarious cameras around the home and make the various feeds available tothe user through a common user interface. Some services provide theability to share these videos with other users, not only via socialnetworks, but also based on other factors. For example, Bot HomeAutomation, Inc. of Santa Monica, Calif., provides camera-equippeddoorbell systems called Ring. Customers get access to the video from theRing cameras via a website, ring.com. One feature of the Ring system iscalled “Ring Neighborhoods” (described athttps://ring.com/neighborhoods). A user can set a radius around theuser's home equipped with Ring cameras and automatically get notifiedwhen other users within that radius share videos in the Ring platform.Users can share any video they find may be interesting for other usersin the neighborhood. However, this system requires the users to reviewall their video to find potentially interesting video and then upload itto share it with other Ring users within a predefined distance.

Another area where cameras are being used is in vehicles. Safety camerasfor backing up or side view cameras are becoming common-place. Forcommercial vehicles, like taxis or other vehicle fleets, security camerasystems record video from both inside and outside the vehicle for safetyand management purposes. For example, Safety Track of Belleville,Michigan, provides a 2-channel dash camera system equipped with a 3G/4Gcellular dongle that connects to the camera system via USB for streamingvideo from the vehicle in real time (described athttp://www.safetytrack_net/dual-lens-in-vehicle-fleet-camera-system/).However, these in-vehicle systems are not simple to install for anaverage consumer and lack any video sharing capabilities with othersystems and do not automatically tag and share events.

What is needed is a video collection and sharing platform that addressesthe deficiencies of the prior art.

BRIEF SUMMARY

According to various embodiments of the present invention, a video datacollection and sharing platform is provided.

In one embodiment,

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 illustrates an exemplary video-based data capture and analysissystem according to one embodiment of the disclosure.

FIG. 2 is a functional block diagram of a client device according to oneembodiment of the disclosure.

FIG. 3 is a block diagram of a dash camera client device according toone embodiment.

FIG. 4a shows a graphical user interface (GUI) for a “clips pane” in amobile app in mobile device 104 according to one embodiment.

FIG. 4b shows a graphical user interface (GUI) for a “camera pane” in amobile app in mobile device 104 according to one embodiment.

FIG. 4c shows a graphical user interface (GUI) for a “news pane” in amobile app in mobile device 104 according to one embodiment.

FIG. 5 is a flow chart illustrating a method of video data collectionaccording to one embodiment.

FIG. 6a a flow chart illustrating a method for cloud-based datacollection and analysis of event-based data according to one embodiment.

FIG. 6b illustrates a data model for capturing metadata associated witha given video data object or file according to one embodiment.

FIG. 6c illustrates a data model for capturing metadata associated witha given event-based video clip according to one embodiment.

FIG. 7 is a flow chart illustrating a method for generating event-basedvideo clips according to one embodiment.

FIG. 8 is a flow chart illustrating a method for sharing event-basedvideo according to one embodiment.

FIG. 9 is a flow chart illustrating a method for verifying authenticityof event-based video data files according to one embodiment.

FIG. 10 is a flow chart illustrating a method for setting up a clientdevice according to one embodiment.

FIG. 11 is a flow chart illustrating a method for an initial set-upprocess according to one embodiment.

The figures depict various example embodiments of the present disclosurefor purposes of illustration only. One of ordinary skill in the art willreadily recognize form the following discussion that other exampleembodiments based on alternative structures and methods may beimplemented without departing from the principles of this disclosure andwhich are encompassed within the scope of this disclosure.

DETAILED DESCRIPTION

The Figures and the following description describe certain embodimentsby way of illustration only. One of ordinary skill in the art willreadily recognize from the following description that alternativeembodiments of the structures and methods illustrated herein may beemployed without departing from the principles described herein.Reference will now be made in detail to several embodiments, examples ofwhich are illustrated in the accompanying figures.

The above and other needs are met by the disclosed methods, anon-transitory computer-readable storage medium storing executable code,and systems for streaming and playing back immersive video content.

Referring now to FIG. 1, an exemplary vehicular video-based data captureand analysis system 100 according to one embodiment of the disclosure isprovided. Client device 101 is a dedicated data capture and recordingsystem suitable for installation in a vehicle. In one embodiment, clientdevice 101 is a video-based dash camera system designed for installationon the dashboard or windshield of a car. Client device 101 is connectedto cloud-based system 103. In one embodiment, cloud-based system 103includes a server system 102 and network connections, such as forexample, to Internet connections. In one embodiment, cloud-based system103 is a set of software services and programs operating in a publicdata center, such as an Amazon Web Services (AWS) data center, a GoogleCloud Platform data center, or the like. Cloud-based system 103 isaccessible via mobile device 104 and web-based system 105. In oneembodiment, mobile device 104 includes a mobile device, such as an AppleiOS based device, including iPhones, iPads, or iPods, or an Androidbased device, like a Samsung Galaxy smartphone, a tablet, or the like.Any such mobile device includes an application program or app running ona processor. Web-based system 105 can be any computing device capable ofrunning a Web browser, such as for example, a Windows™ PC or tablet, MacComputer, or the like. Web-based system 105 may provide access toinformation or marketing materials of a system operations for new orpotential users. In addition, Web-based system 105 may also optionallyprovide access to users via a software program or application similar tothe mobile app further described below. In one embodiment, system 100may also include one or more auxiliary camera modules 106. For example,one or more camera modules on a user's home, vacation home, or place ofbusiness. Auxiliary camera module 106 may be implemented as a clientdevice 101 and operate the same way. In one embodiment, auxiliary cameramodule 106 is a version of client device 101 with a subset of componentsand functionality. For example, in one embodiment, auxiliary cameramodule 106 is a single camera client device 101.

Client device 101 is connected to cloud-based system 103 via connection107. In one embodiment, connection 107 is a cellular-based wirelesspacket data connection, such as a 3G, 4G, LTE, 5G, or similarconnection. Connections 108 a-108 c between other system components andcloud-based system 103 are Internet-based connections, either wired orwireless. For example, in one embodiment, mobile device 104 may atdifferent times connect to cloud-based system 103 via Wi-Fi (i.e., anyIEEE 802.11-based connection or similar technology) and cellular data(e.g., using 4G, LTE, or the like). In one embodiment, Web-based system105 is connected to cloud-based system 103 over the World Wide Web usinga wired Internet connection, such as DSL, cable modem, or the like.Similarly, in one embodiment, auxiliary camera module 106 is connectedto cloud-based system 103 via a Wi-Fi connection to a home routerconnected to the Internet via cable modem, DSL, or the like. Anycombination of available connections can be used to connect any of thesystem components to cloud-based system 103 via the Internet or similarnetworks.

Referring now to FIG. 2, a functional system diagram for a client device101 according to one embodiment is shown. Different embodiments mayinclude a subset of the components shown in FIG. 2 and/or othercomponents not shown. In alternative embodiments, the components shownin FIG. 2 (as well as additional components not shown, such as forexample, HDMI modules, battery charger and/or power supply modules, andthe like) may be part of a System-on-Chip (SoC) device, multiple chipson a board, ASICs, or the like. The physical implementation of thecomponents, either in silicon-based integrated circuits or software areleft as a design choice of the person of ordinary skill in the artwithout departing from the invention. The client device 101 includes amicroprocessor 201 connected to a data bus 202 and to a memory device203 and additional functional modules. In one embodiment, microprocessor201 is a Qualcomm Snapdragon MSM8953 but other microprocessors may beused to implement the invention, such as for example, other Qualcomm'sSnapdragon processors, ARM Cortex A8/9 processors, Nvidia's Tegraprocessors, Texas Instruments OMAP processors, or the like. Themicroprocessor 201executes operating system software, such as Linux,Android, iOS, or the like, firmware, drivers, and application software.

The client device 101 in this exemplary embodiment includes a locationmodule 204, a wireless transceiver module 205, an audio I/O module 206,a video module 207, a touchscreen module 208, a sensor module 209, andan I/O module 216. In this embodiment, the different modules areimplemented in hardware and software modules. In alternativeembodiments, these modules can be hardware, software, or a combinationof both. For example, alternative embodiments may be provided with oneor more central processor (“CPU”) cores on an SoC also including awireless modem, multimedia processor, security and optionally othersignal co-processors, such as for example, one or more graphicsprocessor unit (“GPU”) cores, one or more holographic processing unit(“HPU”) cores, and/or one or more vision processing units (“VPU”). Inone embodiment, one or more SoC processors used to embody the inventionmay encompass CPUs, GPUs, VPUs, HPUs, and other co-processors,motherboard buses, memory controllers, screen controllers, soundchipsets, camera modules, on-board memory, and several peripheraldevices, including for example cellular, Wi-Fi, and Bluetoothtransceivers, as further described below. Alternative embodimentsinclude modules as discrete components on a circuit board interconnectedby bus 202 or a combination of discrete components and one or more SoCmodules with at least some of the functional modules built-in.

In one embodiment, location module 204 may include one or more satellitereceivers to receive and decode signals from location satellite systems,such as Global Positioning System (“GPS”), Global Navigation SatelliteSystem (“GLONASS”), and/or BeiDou satellite systems. In one embodiment,location module 204 is a Qualcomm QTR2965 or Qualcomm QGR7640 receiverthat connects to a GPS antenna for receiving GPS satellite signals andproviding geographical coordinates (latitude and longitude) of thelocation of the client device 101. The wireless transceiver module 205includes a cellular modem, e.g., compliant with 3G/UMTS, 4G/LTE, 5G orsimilar wireless cellular standards, a Wi-Fi transceiver, e.g.,compliant with IEEE 802.11 standards or similar wireless local areanetworking standards, and a Bluetooth transceiver, e.g., compliant withthe IEEE 802.15 standards or similar short-range wireless communicationstandards. In one embodiment, the wireless transceiver module 205 is aSierra Wireless HL-7588.

The audio I/O module 206 includes an audio codec chipset with one ormore analog and/or digital audio input and output ports and one or moredigital-to-analog converters and analog-to-digital converters and mayinclude one or more filters, sample rate converters, mixers,multiplexers, and the like. For example, in one embodiment, a QualcommWCD9326 chipset is used, but alternative audio codecs may be used. Inone embodiment, video module 207 includes a DSP core for video imageprocessing with video accelerator hardware for processing various videocompression formats and standards, including for example, MPEG-2,MPEG-4, H.264, H.265, and the like. In one embodiment, video module 207is integrated into an SoC “multimedia processor” along with processor201. For example, in one embodiment, client device 101 includes anintegrated GPU inside the Qualcomm MSM8953 but alternative embodimentsmay include different implementations of video module 207.

In one embodiment, the touchscreen module 208, is a low-powertouchscreen sensor integrated circuit with a capacitive touchscreencontroller as is known in the art. Other embodiments may implementtouchscreen module 208 with different components, such single touchsensors, multi-touch sensors, capacitive sensors, resistive sensors, andthe like. In one embodiment, the touchscreen module 208 includes an LCDcontroller for controlling video output to the client device's LCDscreen. For example, in one embodiment, touchscreen module 208 includes[actual device used for LCD control]. LCD controller may be integratedinto a touchscreen module 208 or, in alternative embodiments, beprovided as part of video module 207, as a separate module on its own,or distributed among various other modules.

In one embodiment, sensor module 209 includes controllers for multiplehardware and/or software-based sensors, including, accelerometers,gyroscopes, magnetometers, light sensors, gravity sensors, geomagneticfield sensors, linear acceleration sensors, rotation vector sensors,significant motion sensors, step counter sensors, step detector sensors,and the like. For example, in one embodiment, sensor module 209 is andInvensense ICM-20608. Alternative implementations of sensor module 209may be provided in different embodiments. For example, in oneembodiment, sensor module 209 is an integrated motion sensor MEMS devicethat includes one or more multi-axis accelerometers and one or moremulti-axis gyroscopes.

Client device 101 may also include one or more I/O modules 210. In oneembodiment, I/O module 210 includes a Universal Serial Bus (USB)controller, a Controller Area Network (CAN bus) and/or a LIN (LocalInterconnect Network) controller.

In one embodiment, client device 101 also includes a touchscreen 211. Inalternative embodiments, other user input devices (not shown) may beused, such a keyboard, mouse, stylus, or the like. Touchscreen 211 maybe a capacitive touch array controlled by touchscreen module 208 toreceive touch input from a user. Other touchscreen technology may beused in alternative embodiments of touchscreen 211, such as for example,force sensing touch screens, resistive touchscreens, electric-fieldtomography touch sensors, radio-frequency (RF) touch sensors, or thelike. In addition, user input may be received through one or moremicrophones 212. In one embodiment, microphone 212 is a digitalmicrophone connected to audio module 206 to receive user spoken input,such as user instructions or commands. Microphone 212 may also be usedfor other functions, such as user communications, audio component ofvideo recordings, or the like. Client device may also include one ormore audio output devices 213, such as speakers or speaker arrays. Inalternative embodiments, audio output devices 213 may include othercomponents, such as an automotive speaker system, headphones,stand-alone “smart” speakers, or the like.

Client device 101 can also include one or more cameras 214, one or moresensors 215, and a screen 216. In one embodiment, client device 101includes two cameras 214 a and 214 b. Each camera 214 is a highdefinition CMOS-based imaging sensor camera capable of recording videoone or more video modes, including for example high-definition formats,such as 1440p, 1080p, 720p, and/or ultra-high-definition formats, suchas 2K (e.g., 2048×1080 or similar), 4K or 2160p, 2540p, 4000p, 8K or4320p, or similar video modes. Cameras 214 record video using variableframe rates, such for example, frame rates between 1 and 300 frames persecond. For example, in one embodiment cameras 214 a and 214 b areOmnivision OV-4688 cameras. Alternative cameras 214 may be provided indifferent embodiments capable of recording video in any combinations ofthese and other video modes. For example, other CMOS sensors or CCDimage sensors may be used. Cameras 214 are controlled by video module207 to record video input as further described below. A single clientdevice 101 may include multiple cameras to cover different views andangles. For example, in a vehicle-based system, client device 101 mayinclude a front camera, side cameras, back cameras, inside cameras, etc.

Client device 101 can include one or more sensors 215. For example,sensors 215 may include one or more hardware and/or software-basedsensors, including, accelerometers, gyroscopes, magnetometers, lightsensors, gravity sensors, geomagnetic field sensors, linear accelerationsensors, rotation vector sensors, significant motion sensors, stepcounter sensors, step detector sensors, and the like. In one embodiment,client device 101 includes an accelerometer 215 a, gyroscope 215 b, andlight sensor 215 c. FIG. 3, provides an illustrative embodiment of aclient device implemented as a dash camera system according to theinvention.

Referring back to FIG. 1, another component of system 100 is a mobiledevice 104. Mobile device 104 may be an Apple iOS based device, such asan iPhone, iPad, or iPod, or an Android based device, such as forexample, a Samsung Galaxy smartphone, a tablet, a PDA, or the like. Inone embodiment, mobile device 104 is a smartphone with one or morecameras, microphone, speakers, wireless communication capabilities, andsensors. For example, mobile device 104 may be an Apple iPhone 7. Thewireless communication capabilities of mobile device 104 preferablyinclude wireless local area networking communications, such as 802.11compatible communications or Wi-Fi, short-range low-power wirelesscommunications, such as 802.15 compatible communications or Bluetooth,and cellular communications (e.g., 4G/LTE, 5G, or the like). Inaddition, mobile device 104 preferably includes an application programor app running on a processor. One of ordinary skill in the art isfamiliar with mobile operating systems and mobile apps. Mobile apps aretypically made available and distributed through electronic means, suchas for example, via electronic “stores” such as the Apple App Store orthe Google Play Store, or directly from apps providers via their ownwebsites. It should be noted that mobile device app is not required foroperation of the system, for example, camera device 101/108 may includea voice-enabled interface, a chat-bot interface, or the like. However,several embodiments include the use of a mobile app.

A mobile app on mobile device 101 provides a user interface to a useraccount on cloud system 103 and to client device 101. In one embodiment,mobile app includes functionality similar to auxiliary camera 106. Forexample, mobile app uses one or more cameras on mobile device 104 torecord video events in accordance to one embodiment of the disclosure.The video recording, buffer management, and other methods and techniquesdescribed herein may be also incorporated into mobile app in one or moreembodiments of the invention.

Now referring to FIG. 4a-4c , a user interface for an app in mobiledevice 104 according to one embodiment is described. In one embodiment,the mobile app includes one or more panes 401. For example, FIG. 4ashows a graphical user interface (GUI) for a clips pane 401 a in amobile app in mobile device 104 according to one embodiment. The mobileapp can receive video clips from multiple sources and store themlocally. For example, video clips can be received from cloud system 103.Client devices 101, auxiliary cameras 106, and mobile devices 104 of theuser and other users can upload video clips to cloud system 103. Videoclips can also be directly sent to mobile device 104, for example from aclient device 101 or an auxiliary camera 106. Video clips can also belocally generated on mobile device 104. In an alternative embodiment,only metadata for a clip is provided to the mobile app while the videodata for the clip is stored remotely. For example, video data objects(such as for example files, data records, data objects, or the like) maybe stored on cloud servers 102 or in local memory of client devices 101,auxiliary cameras 106, or other mobile devices 104 and remotelyaccessible over the Internet.

According to one embodiment, one or more types video clips from one ormore of these sources can be made available through the clips pane 401 aof mobile app as illustrated in FIG. 4a . Clips pane 401 a includes alisting of video clips that can be accessed by the user via mobiledevice 104. In one embodiment, clips are added to the clips pane 401 aalong with an alert to the user on the mobile device 104. For example,every time a clip is generated by a client device 101, client devicecauses a clip alert to be displayed to the user's mobile device 104 andthe generated clip is listed on clips pane 401 a available for access bythe user. For each available video clip, a descriptor 402 a-n and a cliptype icon 403 a-n are provided. In one embodiment, clip type icon 402provides a visual indicator of the source of the video clip. Forexample, clip type icons 402 a-b indicate that those clips wereautomatically generated via the auto-tagging method (as furtherdescribed below) and clip type 402 c indicates that that clip wasuser-generated. In additional embodiments, these and other clip typesmay be used. For example, in one embodiment, a multi-clip type icon maybe used to indicate availability of multiple clips related to the sameevent, such as for example, multiple clips generated from differentcamera devices providing different viewpoints of the same event asfurther described below. Descriptors 402 provided text associated withthe video clip, such as, for example, a user-generated description or anauto-tag descriptor as further described below. As one of ordinary skillin the art would understand, other icons 403 for different clip typesand descriptors 402 may be used in a clips pane 401 a in accordance withthis disclosure. A user of the mobile app can cause mobile device toplayback a video clip listed in the clips pane 401 a by clicking on ortouching the video clip listing on the clips pane 401 a. The mobile appcauses a media player, either built-in or provided through the operatingsystem of the mobile device 104, to play the selected video clip.

According to one embodiment, live camera feeds from multiple sources canbe displayed on the mobile device 104 through the camera pane 401 b ofmobile app as illustrated in FIG. 4b . In one embodiment, the camerapane 401 b includes a camera feed window 410, a camera control interface411 and a camera selection interface 412. Alternative embodiments mayinclude a subset or additional elements in camera pane 401 b. Forexample, camera selection interface 412 may be not included in asingle-camera embodiment. Camera feed window 410 displays the video feedfrom the currently selected camera. Cameras may be selected using thecamera selection interface 412. For example, camera selection interface412 may display a selection option 412 a-n for each of 1-n availablecameras. In one embodiment, icons are used to depict each of theavailable cameras, such as a home camera (e.g., an auxiliary camera105), a vehicle camera (e.g., from a client device 101), and a phonecamera (e.g., the camera on the mobile device 106). Any number ofadditional cameras may be made available and the selection interface 412modified to allow selection, such as via a drop-down menu, a pop-up“edit” menu, a picker menu, a rolling menu, or the like.

In one embodiment, real time camera feeds are provided to the mobile appwith the same approach used for providing video clips based on aplaylist file or manifest file as further described below. For real-timefeeds, the playlist files are dynamically updated to include each newlygenerated video data object or file captured by the relevant camera. Foreach new video file, the file location is provided in the updatedplaylist and the playlist file is updated via the cloud system 103 ordirectly from the source of the video feed. For example, in oneembodiment, playlist files for streaming video are dynamically updatedas described in the HTTP Live Streaming specification (as for exampledescribed in Internet Draft draft-pantos-http-live-streaming-23submitted by Apple, Inc. to IETF on May 22, 2017) incorporated herein byreference in its entirety. Alternative streaming techniques may be usedin other embodiments, including, for example, MPEG-DASH (ISO/IEC23009-1), Adobe's HTTP Dynamic Streaming, Microsoft's Smooth Streaming,or the like.

In one embodiment, camera pane 401 b includes camera control elements411. For example, a recording or manual tagging control element 411 a isprovided for the user to instruct the currently selected camera togenerate a clip for the currently displayed video (as further describedbelow). For example, if a user is involved in a video-clip-generatingevent, e.g., car accident, police stop, break-in, or the like, inaddition to the any video clips generated through client device 101,either manually or automatically, mobile device 104 can also be used togenerate additional video clips for the given event from a differentangle or perspective. Further, in one embodiment, any time the mobileapp is running on the mobile device 104, one or more cameras on themobile device 104 are recording video data and manual tagging controlelement 411 a is used to generate a manually-tagged video clip asfurther described below. Thus, mobile device 104 can be used as clientdevice 101 or auxiliary camera device 106 according to this embodiment.

In one embodiment, camera pane 401 b may also include additional controlelements 411, such as, buttons, icons, or other selection elements ormenus, to access non-live video stored in the buffer of the currentlyselected camera. For example, a user may remotely access an entire setof video data objects or files stored in the buffer of the user's clientdevice 101 (e.g., video files for the preceding 24 hours) through usercontrol elements 411. In one embodiment, based on the user inputselecting a point in time from which to begin streaming buffered video,the source camera device (e.g., client 101, auxiliary camera 106, orother camera device) generates a dynamic playlist or manifest fileincluding the video files for the next preset time period, for example,one minute, and it is progressively and dynamically updated inincrements of same amount of time (e.g., every minute) with the next setof video files. The playlist or manifest files are generated as furtherdescribed below with reference to video clip generation methods.

Now referring to FIG. 4c , in one embodiment, a mobile app on mobiledevice 104 may also include a news pane 401 c. News pane 401 c providesinformation from a cloud service provider to users. In one embodiment,news pane 401 c may provide the user with links to video clips on cloudservice 103 that are related to video clips generated by the user'sdevice or devices. For example, links to videos from nearby cameradevices generated around the same time as an event video clip of theuser (e.g., a car crash, break-in, or the like) and available from otherusers may be provided to the user on the news pane 401 c. In oneembodiment, requests for sharing a user's video clips may also beprovided via news pane 401 c as further described below.

As noted above, the features described above with respect to the mobileapp may also be provided via Web-based system 105 using conventionalwebsite programming techniques to implement the functionality describedfor the mobile app.

Referring back to FIG. 1, the operation of client device 101 isdescribed in more detail. Preferably, client device 101 includes two ormore cameras 214. For example, in one embodiment, a first “IN” camera214 a is directed at the inside of a vehicle, i.e., the cabin, driver,and passengers, and a second “OUT” camera 214 b is directed at the roadin front of the vehicle. In alternative embodiments, additional cameras214 may be used, for example facing the back and/or sides of thevehicle, multiple interior areas of the vehicle, one or more top camerawith a wide-angle lens providing a 360° view around the vehicle, or thelike.

According to one embodiment, client device 101 is always turned on aslong as it has sufficient power to operate. Cameras 214 a and 214 b arealways turned on and recording video. The video recorded by the cameras214 is buffered in the memory device 203. In one embodiment, memorydevice 203 is configured as a circular buffer. For example, in oneembodiment, memory device 203 may be a 32 Gb FLASH memory device. Clientdevice 101 manages the buffer in memory device 203 to store video datafor a predetermined and programmable set amount of time. For example, inone embodiment, memory device 203 buffers video data from two cameras214 a and 214 b for the preceding 24 hours.

In one embodiment, client device 101 includes software to manage thecameras 214 to control the amount of data, e.g., bytes, generated by thecameras 214 and buffered in memory 203. In one embodiment, cameras 214record data at various selectable video modes and rates. For example,cameras 214 a and 214 b can be set by client device 101 to capture videoat various resolutions, including for example 1440p, 1080p, 720p, 360p,240p, and the like. In addition, the frame rate for the video collectedby each camera 214 can be set by client device 201. For example, in oneembodiment, each camera 214 can independently change its video capturerate from 0 to 30 frames per second.

Now referring to FIG. 5, a method for collecting video for managingvideo buffering according to one embodiment is described. In oneembodiment, various inputs are used to change the resolution and framerate for each available camera. Upon powering up, cameras are set todefault recording settings 501. Multiple inputs are received 502 fromvarious sources. For example, in one embodiment, processor 201 receiveslocation and/or motion data from a location module 204, accelerationdata from an accelerometer sensor 215 a, vehicle status data, such asfor example the revolutions per minute (“RPM”) of a vehicle's engine,vehicle battery charge level, and the like, from I/O module 201connected to a CAN bus, time from wireless module 205 (e.g., LTE networktime), image processing inputs from video module 207 (e.g., facerecognition, human body recognition, etc.), and the like. The inputs areused to determine the relevant features affecting the operation mode ofthe vehicle, such as for example, motion or lack of motion, presence ofa user, presence of a person but not the user, or the like.

Based on the inputs received, an operational mode is determined 503. Forexample, the possible operational modes of a vehicle incorporatingclient device 101 according to one embodiment may include: default,driving, recently parked, parked, armed, low battery, and very lowbattery. Different embodiments can provide a subset or additional modesof operation, which may also vary depending on the vehicle or otherlocation where the client device 101 (or auxiliary camera) may belocated. Table 1 provides an exemplary set of inputs to define eachstatus of a vehicle according to one embodiment. As one of ordinaryskill in the art will appreciate different operational modes anddifferent inputs can be provided without departing from the scope of theinvention.

TABLE 1 Operational Mode Inputs Default n/a Active CAN bus door openand/or engine start, user Bluetooth ID detected. Driving Motion (fromGPS, accelerometer, and CAN bus indicates RPM > 0) Recently Parked Nomotion and engine off for >3 and <5 minutes Parked No motion and engineoff for >5 minutes Armed Face or body detected (but not recognized),accelerometer motion detected Low Battery No motion, CAN bus (Batterylevel) below threshold. Very Low Battery CAN bus (Battery Level) belowsecond threshold

A status change is determined at step 504. For example, after poweringup, input data is received and the operational mode is no longer in“Default” mode. Based on the determined operational mode, the camerasettings (e.g., resolution and frame rate) are changed 505 to producemore or less data for the video being recorded. For example, Table 2provides exemplary camera settings for a two-camera client device 101 ina vehicle with an “IN” camera 214 a and “OUT” camera 214 b according toone embodiment. As one of ordinary skill in the art will appreciate,different settings for different numbers of cameras and operationalmodes can be provided without departing from the scope of the invention.

TABLE 2 Operational Mode OUT Camera Settings IN Camera Settings Default720 p, 15 fps 720 p, 15 fps Active 720 p, 30 fps 720 p, 30 fps Driving1440 p, 30 fps 1080 p, 30 fps Recently Parked 720 p, 30 fps 720 p, 15fps Parked 720 p, 15 fps 360 p, 15 fps Armed 1440 p, 30 fps 1440 p, 30fps Low Battery 240 p, 1 fps 240 p, 1 fps Very Low Battery Off Off

Once the camera settings have been changed, recording of the video isdone 506 using the camera settings. This results in video data objects,records, or files of varying size to manage the buffer, storing higherquality data with more bits during operational modes with higherlikelihood of capturing video for events of interest while using lowerquality data with less bits during operational modes with lowerlikelihood of capturing video of interest.

In an alternative embodiment, as illustrated in FIG. 5, additionalactions may be associated with the various operational modes. In thisembodiment, the method checks 507 if the operational mode requiresadditional actions. If so, the actions are performed at step 508. Forexample, in one embodiment, upon determining the “Low Battery” mode,client device 101 sends a notification to the user, for example via theapp on the mobile device, a text message, an email, or the like. Asanother example, if the “Very Low Battery” mode is determined, thesystem may send as similar user notification and then turn off.Similarly, a “Buffer Size Limit” mode may be determined if the amount ofdata generated within the given time period (e.g., 24 hours) is going toexceed the size of the buffer and the system may have to rewrite overstored video data before the time period expires, for example, if thesystem is being used for extended periods of time. In that case, inaddition to reducing the camera settings, the system may also send anotification to the user. As one of ordinary skill in the art willunderstand, different actions may be associated with different modes toprovide additional functionality to the system within the scope of theinvention. If one of the actions does not turn off the system, thenrecording can continue at step 506 as described above.

According to another aspect of one embodiment, the buffer managementmethodology used in client device 101 will optimize the memory availablefor buffering to ensure that video data is not stored on the memorydevice for longer than a preset, programmable amount time. For example,if the buffering time is set to 24 hours, client device 101 may changethe camera settings to change the size of the video data objects orfiles to ensure that “stale” video data is written over by new videodata as the 24-hour limit approaches. For example, in one embodiment,even if the vehicle operational mode is determined to be “Parked,”processor 201 may over-write the mode to the camera settings associatedwith the “Driving” mode to ensure that older video data is written overin the circular buffer. In the case where even when using the highestquality video and maximum frame rate available some of the video data inthe buffer remains after 24 hours, the system deletes the video data.

According to another aspect of the invention, in one embodiment, thebuffer management methodology further includes a learning function tofurther optimize the storage of video data in the device's buffermemory. According to one embodiment, the camera device monitors the useof the camera device and creates history of use data for furtherapplication to buffer management algorithms. For example, in oneembodiment, the times when each mode is activated and for how long eachmode is activated is recorded. The buffer management methodology thenuses the mode history information to optimize use of the buffer and/orto avoid buffer overrun. For example, the percentage of the buffer usedwithin the current 24-hour timeframe and the expected use for remainingtime based on history information is considered at the camera settingschanging step 505 to reduce or increase camera quality settings for agiven mode. For example, after determining that the Driving mode shouldbe set at the 20^(th) hour of a 24-hour period, the method furtherchecks the percent usage of the buffer and determines to have excesscapacity, e.g., at 50% when historically it would be at 80%, anddetermines based on historical use data that for the next 4 hours of the24-hour period it is expected to use 20% of the buffer. Since the bufferis being underutilized, the method increases the quality of video datafor the Driving mode, for example, to 1440p/30 fps for both cameras.

In another embodiment, a vehicle-mounted client device 101 includes alearning algorithm for buffer management that learns the user's typicalschedule for driving and corresponding modes (morning commute, parkeduntil noon, lunch “drive”, after noon “parked”, etc.) and considers theexpected use of the buffer at each given time. In this embodiment, ifone day there are some unusual events causing modes that require higherquality camera settings earlier in the 24-hour period, later in the daythe camera settings of lower quality settings modes, e.g., Parked mode,can be further reduced to lower resolution and frame rate than thenormal settings for that mode. Alternatively, direct user input may alsobe provided to indicate a change in the typical operation schedule. Forexample, the user may indicate the use of the system for an extendedroad trip and the user input is used to override the expected schedulefor that time frame.

According to another aspect of the invention, in one embodiment, thebuffer usage history data learned by the system is further input to theoperational mode determination step 503. In this embodiment, a weightingfunction is used to determine a probability for each operating modebased on the strength of the combination of inputs. For example, if theGPS input indicates no motion but the CAN bus input indicates some RPM,the confidence of the motion component for the mode determination islower than if both the GPS and the CAN bus inputs both indicate nomotion. Similarly, a face recognition positive input would increase theprobability of the mode being “Driving Mode.” Optionally, the confidencelevel of any image recognition input is also use as a weighting factorfor the mode determination. For example, the confidence or likelihood ofa positive image recognition match (e.g., the likelihood of a positiverecognition of a face, the user's face, a body, a uniform, flashinglights, etc.) is used as a multiplier to the contribution of the matchto the mode determination. The determination of the operating mode isset if the various probabilities from the multiple inputs exceed athreshold. In one embodiment, the mode probability thresholds arechanged based on historical buffer usage data. For example, if thebuffer storage is above the expected usage level for a given time withinthe buffer storage period (e.g., 24 hours), a higher threshold is usedto determine a mode that uses higher definition/frame rate. Conversely,if the buffer storage is underutilized based on the historical use data,the mode threshold for the same modes can be reduced.

Now referring to FIG. 6a , a method for capturing and storing videoaccording to one embodiment is provided. As noted above, video camerasin the various devices are preferably always on and recording video.Once video is being recorded, the method beings 601 and continues untilthe device is turned off or, in the case of a mobile device 104, untilthe mobile app stops running. For each camera, the image sensorgenerates video data according to the camera settings for the currentoperational mode as described above with reference to FIG. 5. The videodata is received 602 and the video for each preset time period isencoded 603 according to a video compression and encoding standard, suchas for example, MPEG-4, H.264, H.265, or any other video compression andencoding standard. The time period for each block of video may bepredetermined or variable (e.g., based on user settings) and may be, forexample, 2, 4, 6, or 10 seconds. In one embodiment, every two seconds ofvideo is encoded together into a video data object, record, or file.Other embodiments may use different time periods depending, for example,on the intended use of the video, the purpose for the system, thelocation where the system is deployed, the amount of memory available,the processing power available, or other relevant factors. Metadata forthe same time period is also captured 604 as information associated withthe captured video data. As part of the metadata capture 604, a globallyunique ID (“GUID”) is generated to uniquely identify the video data andmetadata for the time period.

In one embodiment, the video data is encrypted 605. Any encryptionalgorithm may be used, such as, for example encryption algorithmscompliant with the Advanced Encryption Standard (AES), Blowfish,Twofish, Data Encryption Standard (DES) (e.g., Triple-DES), RSA, or thelike. Preferably, the video data is encrypted 605 based on auser-specific encryption key. In a vehicle-based embodiment, anencryption key is provided for each driver authorized to drive thevehicle. For example, in this embodiment, a biometric input from thedriver is required to operate the system, such as, a fingerprintrecognition, a voice recognition, or a face recognition basedidentification is used to identify the authorized driver. For eachauthorized driver, a corresponding randomly generated encryption key ismaintained in a data table. Any video generated while the authorizeddriver is determined to be driving the vehicle is encrypted 605 usingthe driver-specific key. Subsequently, in order to provide privacy, onlythe authorized driver can provide access the encrypted video usingbiometric identification.

In another embodiment, video encryption 605 is based on other forms ofuser identification. For example, in one embodiment, the Bluetooth IDfor the mobile device 104 of an authorized user is used foridentification. In this embodiment, for example, a client device 101 maydisplay the picture or pictures of the users for which the client device101 has recognized the presence of their associated Bluetooth IDs. Therecognized user who is driving can select his or her picture on thescreen on the client device 101 and the corresponding encryption key isused for encrypting video. Alternative approaches for selecting theencryption key may be used in other embodiments. For example, ahierarchical level of authorized users may be provided, such as, anowner level versus a guest level or a parent level versus a child level,such that the encryption key for the highest level of authorized userrecognized is used to encrypt the video in situations where multipleauthorized users are detected. Alternatively, in some embodiments, theencryption 605 may not be user-based. For example, the encryption keymay be a random key that is unique to each device. Moreover, is someembodiments the system may record video in un-encrypted form omittingstep 605.

According to another aspect of the invention, several other privacymeasures may optionally be provided for passengers of a vehicle with acamera device in one embodiment. For example, for ride-sharingapplications, customer/passengers may want to protect their privacy frominformation capture by client device 101. In this embodiment, aride-sharing mobile device app provides privacy features customizable bythe user. Upon detection of the user/customer in the vehicle, clientdevice 101 retrieves privacy settings for the detected passenger andapplies them accordingly. For example, using face recognition, BluetoothId, or other means of recognizing the passenger, ride-sharingpassengers' preferences may be applied on client device 101, such asturning certain cameras on or off, blurring video or parts of the video(e.g., faces), storing more or less of the sensor data collected, and/orenabling or disabling other features of the client device 101. In oneembodiment, customers' qualifications may be required to provide accessto customizable preferences, which may be accessible in different tiers,for example based on continued usage of the ride-sharing service (e.g.,loyalty points/levels), payment levels, or the like.

Referring back to the method of FIG. 6a , the encrypted video data andassociated metadata for the given time period are stored 606 in thebuffer. The resulting video data object or file will be of varying sizebased on the camera settings (e.g., resolution, frame rate, etc.)applied as well as any other factors, such as applied compression formatand encoding. The video data object is then hashed 607 using a one-wayhash function, such as SHA, MD5, or similar algorithm, to generate aunique hash for the captured video, i.e., the video data hash.Optionally, the hashing function may be applied to a file that includesboth the video data and metadata. Alternatively, the metadata may bestored separately but in association with the video data and it is notincluded in the generation of the hash 607.

In one embodiment, a message is generated 608 including the metadata foreach time period and the corresponding video data hash. Preferably, themessage is then cryptographically signed 609 to guarantee the messagepayload originates from an authorized device. For example, a private keyassociated with a system-authorized device may be used to generate aone-way hash of the message payload. In an alternative embodiment, theprivate key is used to encrypt the payload of the message. In oneembodiment, each client device 101, auxiliary camera 106, and mobiledevice 104, is associated with a unique cryptographic key-pair. Thedevice securely stores the private key. The cloud system 103 retainsaccess to the public keys for each device so it can verify that messagesit receives come from authorized devices. For example, cloud system 103maintains a set of records uniquely associating a device ID for eachauthorized device in the system with a corresponding public key that isapplied to messages received from the device. For example,private-public-key cryptographic signature methodologies may be used toverify that each received message includes a signature or encryptedpayload encrypted with a private key from an authorized device.

In yet another embodiment, at step 607, optionally, instead of hashingthe video data object, the client device uses its private cryptographickey to cryptographically sign or otherwise encrypt the video data objectitself, for example, if the actual video data object is to be sent orotherwise uploaded to another device, such as cloud system 103. Thiscould optionally be done in conjunction with step 609 as describedabove.

Finally, the message is sent 610 to the cloud system. Preferably, themessage is sent using a secured connection, such as for example, anSSL/HTTPS connection over TCP/IP or the like. The process then repeatsfor the video data and metadata captured in the subsequent time period.Preferably, the time required to perform the process of FIG. 6a is lessthan the selected time period. For example, a device capturing videodata in two-second increments (the time period) sends the metadata andvideo hash message to the cloud system 103 every two seconds. If at somepoint the data connection to the cloud is interrupted or otherwisebecomes unavailable, the system may locally cache the messages fortransmission upon reconnection to the cloud system 103.

In an alternative embodiment, the message signing step 609 is omitted.Instead, a device establishes a secured connection with the cloud system103, such as an SSL/HTTPS connection, and authenticates itself to theserver 102. For example, a device provides its device ID and acryptographically signed version of its device ID, signed with thedevice's private key. The server 102 retrieves the public keycorresponding to the device ID provided and verifies the signed deviceID for a match. Upon authorization, the server provides the device witha session token that uniquely identifies communications from that devicefor a given session. Thereafter messages are sent 610 over the securedconnection with the metadata and video hash and also including theserver-provided token.

Now referring to FIG. 6b , a data model for capturing metadataassociated with a given video data object or file is provided accordingto one embodiment. In one embodiment, the video-object metadata 620 isperiodically sent to cloud system 103 as device telemetry information.In one embodiment, the telemetry information 620 is sent after therecording of each video object, e.g., every 2 seconds, 6seconds, 8seconds, 10 seconds, or the like. The video-object metadata 620 mayinclude one or more metadata items including, for example, a device ID621, an atomic clock time stamp 622, a GPS timestamp 623, a latitudevalue 624, a longitude value 625, an altitude 626, a speed 627, acompass heading 628, a horizontal accuracy value 629, a verticalaccuracy value 630, a software version 631, a location string value(e.g., a “geohash”) 632, a connection type identifier (e.g., 2G, 3G, 4G,WiFi, etc.) 633, a wireless signal strength value 634, and/or a carrieridentifier 635. One of ordinary skill in the art would understand thatany combination of these metadata values may be used depending on theimplementation and intended use of the metadata.

Now referring to FIG. 6c , a data model for capturing metadataassociated with a given event-based video clip, such as an automaticallygenerated video clip, a user-generated video clip, or the like, isprovided according to one embodiment. In one embodiment, the eventmetadata 650 is generated and stored with each video clip. The eventmetadata 650 may include one or more metadata items including, forexample, device ID 651, an atomic clock time stamp 652, a locationstring value (e.g., geohash) 653, an event or tag type 654, an event ortag type 655, an event or tag title 656, an event or tag latitude value657, an event or tag longitude value 658, an event or tag altitude 659,an event or tag speed 660, an event or tag compass heading 661, an eventor tag horizontal accuracy value 662, an event or tag vertical accuracyvalue 663, the full file name for the an event or tag clip file (e.g.,manifest file) 664, a software version 665, a device type ID 664, andone or more Boolean variables to indicate whether the event or tag cliphas been viewed 665 a, shared 665 b, deleted 665 c, etc.

Now referring to FIG. 7, a method for generating event-based video clipsaccording to one embodiment is described. Upon activation of the system,the method starts 700. The various inputs are monitored 701 while videois continuously captured. If no tagging event is detected 702, thesystem keeps monitoring. If a tagging event is detected 702, therelevant video data in the buffer is identified and selected 703. Forexample, once an event is detected 702, the video files for a predefinedperiod of time before and after the event is identified in the buffer.In one example, 15 seconds before and after the event time is used. Theamount of time, preferably between 10 and 30 seconds, may bepre-programmed or user selectable. Further, two different time periodsmay be used, one for time before the event and the other for time afterthe event. In one embodiment, the time periods may be differentdepending on the event detected. For example, for some events the timeperiods may be 30 seconds before event and 1 or 2 minutes after whileother events may be 15 seconds before and 15 seconds after.

The selected video data is marked for buffering 704 for a longer periodof time. For example, the video files for the selected time period arecopied over to a second system buffer with a different buffering policythat retains the video for a longer period of time. In one embodiment,the selected video data being in a buffer storing video for 24 hours ismoved over to a second buffer storing video for 72 hours.

Referring back to FIG. 7, a video clip is then generated 705 with theselected video data. Like every video data object, every video clipgenerated is associated with a globally unique identifier (GUID). In oneembodiment, video clips are generated using a playlist file or manifestfile as is known in the art. Each playlist or manifest file includes aGUID. For example, in one embodiment, an m3u8 playlist file is generatedaccording to the HTTP Live Streaming specification (as for exampledescribed in Internet Draft draft-pantos-http-live-streaming-23submitted by Apple, Inc. to IETF on May 22, 2017). Alternative videoclip generating techniques may be used in other embodiments, including,for example, MPEG-DASH (ISO/IEC 23009-1), Adobe's HTTP DynamicStreaming, Microsoft's Smooth Streaming, or the like. The playlist ormanifest file provides network-based location for the video data objectsselected 703. For example, a Universal Resource Locator (URLs) may beprovided for each of a set of video files. Using this approach, thevideo data can be stored in any network accessible storage. For example,video files identified in a given playlist can be stored on a cameradevice (e.g., client device 101, auxiliary camera 106, or mobile device104) and network address locators are provided for each file at thatlocation. In alternative embodiments, other video clip generationapproaches may be used. For example, in one embodiment, the selected 703video data is used to generate a single video file, such as an MPEGvideo file, that may be uploaded and downloaded as needed.

In one embodiment, video data objects are stored on thenetwork-accessible buffer of the camera device and the playlist ormanifest files for the generated event-based video clips identify thenetwork addresses for the memory buffer memory locations storing thevideo data objects or files. Alternatively, upon identifying andselecting 703 the relevant video data objects, in addition to or as analternative to moving the video data to the longer buffer 704, the videodata may be uploaded to the cloud system 103. The clip generation 705then identifies in the playlist or manifest file the network addressesfor the video data stored in the cloud system 103. A combination ofthese approaches may be used depending on storage capacity and networkcapabilities for the camera devices used in the system or according toother design choices of the various possible implementations.

In one embodiment, other system components, such as the cloud system 103or mobile device 104, are notified 706 of the event or event-based videoclip. For example, in one embodiment a message including the GUID forthe generated video clip is sent to the cloud system in acryptographically signed message (as discussed above). Optionally, theplaylist or manifest file may also be sent in the message. In oneembodiment, the playlist or manifest files are maintained in the localmemory of the camera device until requested. For example, uponnotification 706 of the clip generation, the cloud system may requestthe clip playlist or manifest file. Optionally, the cloud system maynotify 706 other system components and/or other users of the clip andother system components or users may request the clip either from thecloud system 103 or directly from the camera device. For example, theclips pane 401 a in the user's mobile app may display the clipinformation upon receiving the notification 706. Given that the clipmetadata is not a large amount of data, e.g., a few kilobytes, the userapp can be notified almost instantaneously after the tag event isgenerated. The larger amount of data associated with the video data forthe clip can be transferred later, for example, via the cloud system ordirectly to the mobile device. For example, upon detection of a“Baby/Animal in Parked Car” event or a “Location Discontinuity” event,the user's mobile device 104 may be immediately notified of the tagevent using only tag metadata. Subsequently, the user can use the videoclip playlist to access the video data stored remotely, for example, forverification purposes.

Once a video clip is generated 705, it may be shared with other devicesowned by the same user or, if authorized, the video clip may be sharedwith other users of the system. For example, the GUIDs for every videoclip generated by a camera device of a given user may be stored in auser clip table in the cloud system 103. For example, GUIDs for theclips from all the cameras on a multi-camera client device 101, for theclips from any auxiliary camera device 106, and for the clips generatedby the mobile app on the user's mobile device 104, may all be stored inthe user clip table. The user may access the user clip table via mobiledevice 104. For example, mobile app may maintain a user clip table thatis synchronized with the user clip table in the cloud system. Every timea new clip notification is received, the mobile app and cloud-based userclip tables are updated and or synchronized. Alternative synchronizationapproaches may be used, such as for example a periodic synchronizationapproach.

In addition to the GUID, in one embodiment, the user clip tables mayalso include other information or metadata for each clip of the user,such as for example, a name or descriptor, device ID where the video wascaptured, time and date information, tag or event information,thumbprint images, or the like. Further, the playlist or manifest filemay also be stored or identified in the user clip table. In oneembodiment, a user may access video clips through the mobile app on themobile device 104 through the clip pane 401 a. Upon selection of a clipthrough the clip pane 401 a, the mobile app uses the clip GUID torequest the corresponding playlist or manifest file from the cloudsystem 103, directly from a camera device (e.g., client device 101 orauxiliary camera 106). Using the playlist or manifest file, the mobileapp can playback the video clip by requesting the relevant video objectsusing their network address identifiers. In one embodiment, if the videodata objects are encrypted, the user may provide an identification(e.g., biometric ID, face recognition, user ID and password, or thelike) to access the decryption key as further discussed above.

According to one embodiment, video clips generated by devices registeredunder the same user account are automatically shared with the user.According to another aspect of the disclosure, a user may also sharevideo clips with other users through the system or using other Internetmessaging or connectivity. For example, in one embodiment, mobile app onmobile device 104 (or website on Web-based system 105) includesfunctionality to link or publish video clips to social media sites ornetworks, such as Facebook, Twitter, Google Plus, or other sites fromsocial networking platforms. Video clips can also be shared directly viaemail, text messaging, or similar electronic communication approaches,or otherwise exported to other computer systems. In one embodiment,cloud system 103 stores video data for a given video clip in a publiclyaccessible network storage location. Cloud system 103 may be accessedvia the Internet by anyone with an event-based video clip playlist ormanifest file as is known in the art. A user may share the playlist ormanifest file, either directly or via a network link, such as a URL, tothe playlist or manifest file stored on an Internet-accessible storagelocation, for example, on cloud system 103 or any other similarlocation.

According to another aspect of the disclosure, video clips may also beshared automatically with other users of the system. For example, uponjoining the system, the user may be presented with a number of optionsto pre-authorize the sharing of the user's video clips with other usersof the system. In one embodiment, users have the option to pre-authorizeaccess to video clips generated by certain camera devices. For example,the user may authorize the sharing of video clips generated with videodata captured by an “OUT” camera on a vehicle-based system. Optionally,the user may impose restrictions on the video clips that are shared withother users. For example, a user may only allow sharing of video clipsof a certain video quality, with or without sound, or the like. Forexample, a user may authorize the sharing of video clips from an “IN”camera in a vehicle-based system but without any audio. Optionally,another option for pre-authorization of access to a user's video clipsmay be based on location. For example, the user may pre-authorize accessto video clips generated by a “home” auxiliary camera 106 to other usersregistered in locations within a pre-defined radius, e.g., neighbors.The location of camera devices that are part of the system can beidentified by IP address lookup, GPS location (e.g., from a smartphonedevice, client device, or the like) or my manual entry of location. Anytime a new user joins, the location of the user (e.g., a home address,preferred location, or the like) is used to determine nearby existingusers. For example, in one embodiment, the distance between every pairof users is calculated and maintained in a database and a pre-definedradius or distance limit is applied to designate which users are“nearby” with respect to other users, for example by adding a flag touser's whose pairwise distances are below the pre-defined radius. In oneembodiment, during the sign-in process, the system sends a consentrequest to existing users to share with the new users. Alternatively, inanother embodiment, upon signing on to the system, every userpre-authorizes the sharing of at least some camera-specific video with“neighbors” or “nearby” users. Additionally, the user may be allowed toprovide additional restrictions with respect to the video clips that maybe shared with neighbors. According to another aspect of the video clipsharing functionality, users may mark individual video clip with asharing designation. In one embodiment, this sharing designation wouldoverwrite any other pre-authorization, such that a user would havecontrol of which video clips may be shared and which ones may not.Additional techniques for sharing video clips are further discussedbelow, such as for example, accessing of shared neighbors' video viaWeb-based system 105 or mobile device 104.

According to another aspect of the disclosure, detection of taggingevents 702 may be done automatically by the system. For example, basedon the monitored inputs, in different embodiments events such as avehicle crash, a police stop, or a break in, may be automaticallydetermined. The monitored inputs 701 may include, for example, imageprocessing signals, sound processing signals, sensor processing signals,speech processing signals, in any combination. In one embodiment, imageprocessing signals includes face recognition algorithms, bodyrecognition algorithms, and/or object/pattern detection algorithmsapplied to the video data from one or more cameras. For example, theface of the user may be recognized being inside a vehicle. As anotherexample, flashing lights from police, fire, or other emergency vehiclesmay be detected in the video data. Another image processing algorithmdetects the presence of human faces (but not of a recognized user),human bodies, or uniformed personnel in the video data. Similarly, soundprocessing signals may be based on audio recorded by one or moremicrophones 212 in a camera device, (e.g., client device 101, auxiliarycamera 106, or mobile device 104). In one embodiment sound processingmay be based on analysis of sound patterns or signatures of audio clipstransformed to the frequency domain. For example, upon detection of asound above a minimum threshold level (e.g., a preset number ofdecibels), the relevant sound signal is recorded and a Fast FourierTransform (FFT) is performed on the recorded time-domain audio signal asis known in the art. The frequency-domain signature of the recordedaudio signal is then compared to known frequency domain signatures forrecognized events, such as, glass breaking, police sirens, etc. todetermine if there is a match. For example, in one embodiment, pairs ofpoints in the frequency domain signature of the recorded audio input aredetermined and the ratio between the selected points are compared to theratios between similar points in the audio signatures of recognizedaudio events.

Sound processing may also include speech recognition and naturallanguage processing to recognize human speech, words, and/or commands.For example, certain “trigger” words may be associated with particularevents. When the “trigger” word is found present in the audio data, thecorresponding event may be determined. Similarly, the outputs of theavailable sensors may be received and processed to determine presence ofpatterns associated with events. For example, GPS signals, acceleratorsignals, gyroscope signals, magnetometer signals, and the like may bereceived and analyzed to detect the presence of events. In oneembodiment, additional data received via wireless module 205, such astraffic information, weather information, police reports, or the like,is also used in the detection process. The detection process 702 appliesalgorithms and heuristics that associate combinations of all thesepotential inputs with possible events.

The following Table 3 provides exemplary inputs, rules, and heuristicsfor corresponding events according to one embodiment of the invention ina vehicle implementation. While a set of specific examples is provided,it is understood that the present invention can be applied to a widevariety of inputs, rules, and heuristics that can identify otherpossible events, depending on the application.

TABLE 3 Inputs, Rules, and Heuristics Possible Event Sound “IN” cameraabove threshold and Break-in/Burglar close match to glass breaking soundsignature GPS—no motion Accelerometer—small vibrations CAN bus—engineoff IN camera—object motion detected or unrecognized face detected Noauthorized user Bluetooth ID GPS—location in a freeway or Police Stophighway—stop after speed above posted limit Traffic data—noslowdown/heavy traffic reported Accelerometer—small vibrations CANbus—low RPM (idle) or off IN camera—flashing lights detected/policevehicle detected/uniformed personnel detected OUT camera—road shoulderdetected/ police vehicle detected/uniformed personnel detectedSound—sirens detected GPS—no current motion Accident/Car CrashAccelerometer—threshold deceleration exceeded Gyroscope—thresholdangular acceleration exceeded Sound—specific “distressed words”identified/loud crashing sounds detected GPS—no current motionBaby/Animal left Accelerometer—minor motion or no in parked vehiclemotion (Recently Parked Mode) Sound—possible animal sounds or babycrying Image recognition IN camera—possible optical flow indication ofmovement inside vehicle or human/baby face recognition Prior GPS readingindicating location Location Discontinuity exceeding a maximus distancefrom current (vehicle transported/ location upon power up stolen) Timegap from last operation exceeding maximum time limit

These combinations of events and inputs are illustrative only. Someembodiments may provide a subset of these inputs and/or events. Otherembodiments may provide different combinations of inputs and/ordifferent events. The event detection algorithms may be implementedlocally on the camera device (e.g., client device 101) or may beperformed in cloud servers 102, with the input signals and eventdetection outputs transmitted over the wireless communication connection107/108 from and to the camera device. Alternatively, in someembodiments a subset of the detection algorithms may be performedlocally on the camera device while other detection algorithms areperformed on cloud servers 102, depending for example, on the processingcapabilities available on the client device. Further, in one embodiment,artificial intelligence (“AI”) algorithms are applied to the multipleinputs to identify the most likely matching event for the givencombination of inputs. For example, a neural network may be trained withthe set of inputs used by the system to recognize the set of possibletagging events. Further, a feedback mechanism may be provided to theuser via the mobile app to accept or reject proposed tagging results tofurther refine the neural network as the system is used. This provides arefinement process that improves the performance of the system overtime. At the same time, the system is capable of learning to detectfalse positives provided by the algorithms and heuristics and may refinethem to avoid incorrectly tagging events.

Referring back to FIG. 5, in one embodiment, upon detection 702 of anevent, determination of operational mode 503 sets the operational modeto a high-quality settings mode, such as “Armed” or the like.Alternatively, an “Event” operational mode may be provided that maycause a camera settings change 505, to a high-quality setting, such as,for example 1440p and 30 fps for all cameras.

According to another aspect of the disclosure, in one embodiment, thedetection process 702 is configured to detect a user-determined manualtagging of an event. The user may provide an indication to the system ofthe occurrence of an event of interest to the user. For example, in oneembodiment, a user may touch the touchscreen of a client device 101 toindicate the occurrence of an event. Upon detecting 702 the user “manualtag” input, the system creates an event-based clip as described abovewith reference to FIG. 7. In an alternative embodiment, the userindication may include a voice command, a Bluetooth transmitted signal,or the like. For example, in one embodiment, a user may utter apredetermined word or set of words (e.g., “Owl make a note”). Upondetecting the utterance in the audio input, the system may provide a cueto indicate the recognition. For example, the client device 101 maybeep, vibrate, or output speech to indicate recognition of a manual tag.Optionally, additional user speech may be input to provide a name ordescriptor for the event-based video clip resulting for the user manualtag input. For example, a short description of the event may be utteredby the user. The user's utterance is processed by a speech-to-textalgorithm and the resulting text is stored as metadata associated withthe video clip. For example, in one embodiment, the name or descriptorprovided by the user may be displayed on the mobile app as the clipdescriptor 402 in the clips pane 401 a of the mobile app. In anotherembodiment, the additional user speech may include additional commands.For example, the user may indicate the length of the event for which themanual tag was indicated, e.g., “short” for a 30-second recording,“long” for a two-minute recording, or the like. Optionally, the lengthof any video clip can be extended based on user input. For example,after an initial event-based video clip is generated, the user mayreview the video clip and request additional time before or after andthe associated video data is added to the playlist or manifest file asdescribed with reference to FIG. 7.

In one embodiment, the tagging process may optionally be programmable.For example, camera device may be programmed to recognize traffic signsusing image recognition and a classifier and to capture and storemetadata associated with the recognized sign. For example, stop signsmay be detected and the speed or other sensor data may be recorded asmetadata associated with the stop sign. This feature may be used bythird-parties for monitoring driving behavior. For example, parents canmonitor children, insurance companies can monitor insureds, employerscan monitor employees, etc. Optionally, in one embodiment the cameradevice may provide driver feedback based on the detected signs andsensor data. For example, in one embodiment, the camera device mayrecognize street parking signs and notify the user regarding parkinglimits. For example, the device may alert the user regarding a “NoParking” zone, a limited time parking zone, and/or remind the user priorto the expiration of a parking time limit with sufficient time for theuser to return to the vehicle (e.g., based on the sign imagerecognition, time, and location information). One of ordinary skill inthe art would recognize the additional applications of driver feedbackare possible within the scope of the invention, such as for example,feedback regarding speeding, traffic light/sign compliance, safety, orthe like.

In another embodiment, the programmable tagging may be accessedremotely, e.g., via cellular communications module 205, to provide imagequeries remotely. For example, in one embodiment, license plate and/orcar image queries associated with an “Amber Alert” may be provided byauthorities via cloud system 103 to all camera devices in the system.According to one embodiment, standard “definitions” of image queries canbe shared amongst cameras ahead of time so that all cameras can belooking for a specific object or item. Optionally, the image queries mayinclude a timing component to specified an amount of time during whichcamera devices may periodically run the image query. For example, anAmber Alert may provide one or more image queries (e.g., a license plateand/or a specific vehicle brand and/or color) to be searched for someamount of time, for example during 24 hours. Optionally, in oneembodiment, the user may also provide programmable tagging instructions,for example via mobile device app or Web-based interface. For example,in one embodiment, the user may schedule a tag generation event forcapturing video data at a particular time, or may remotely instruct thecamera device to start recording on command.

Now referring to FIG. 8, a method for identifying and sharingevent-based video clips is described. In addition to the various optionsfor sharing video clips identified above, in one embodiment, video clipsmay also be shared based on their potential relevance to eventsgenerated by different camera devices. To do so, in one embodiment, avideo clip sharing request is received 800. The video clip sharingrequest 800 may be user-generated or automatically generated. Forexample, in one embodiment, a map can be accessed displaying thelocation of camera devices for which a user may request shared access.The user can select the camera device or devices it wants to requestvideo from. In an alternative embodiment, the user enters a location,date, and time for which video is desired to generate a sharing request.

In yet another embodiment, a user may select an object (e.g., a car,person, item, or the like) being displayed on the screen of a cameradevice. For example, via a tap on a touchscreen of a client device 101while video is being played, using voice commands, or other user inputdevice capable of identifying objects being displayed on a video.Optionally, an object of interest can also be identified on a videoautomatically. For example, as part of the auto-tagging featuredescribed above with reference to FIG. 7, some of the inputs monitored701 may include objects of interest resulting from image processingtechniques. For example, if a tagging-event is determined to be abreak-in and one of the monitored inputs includes a detected human facethat is not recognized, the unrecognized face may be used as theselected object.

Image processing algorithms and/or computer vision techniques areapplied to identify the selected object from the video and formulate anobject descriptor query. For example, the user input is applied todetect the region of interest in the image, e.g., the zoomed-in region.The data for the relevant region is processed into a vectorrepresentation for image data around detected relevant points in themage region. From the vector or descriptor of the relevant region,feature descriptors are then extracted based on, for example,second-order statistics, parametric models, coefficients obtained froman image transform, or a combination of these approaches. Thefeature-based representation of the object in the image is then used asa query for matching in other video data. In one embodiment, a requestfor sharing video clips includes an image query for an object andmetadata from the video data in which the object was detected.

Referring back to FIG. 8, in one embodiment, upon receiving the sharingrequest 800, from the metadata provided with the request, the relevantmetadata for sharing video clips from other camera devices is obtained801. For example, in one embodiment, the request may include thelocation, date and time for the desired video. In another embodiment,the GUID of the video data object from which the object was detected.Using the GUID, the metadata file for that video data object is obtained801 and metadata for that video object is accessed. For example, a cloudsystem 103 stores the metadata for all the video data objects in thesystem. The metadata may be indexed by the GUIDs of the video objects.In an alternative embodiment, the request for sharing video clipsincludes relevant items of metadata from the video object in which theobject of interest was found. For example, the request may include alocation (e.g., geo-coordinates, GPS data, or the like), a cameraorientation (e.g., a magnetometer reading), and time (e.g., atomic timedata from a 4G/LTE system) from the camera device that recorded thevideo data.

Using the obtained metadata values, a set of relevant camera deviceswith video data responsive to the request, that for example may includethe same object of interest or match the desired location, date, time,and/or orientation, is identified 802. In one embodiment, to respond toan image-query-based request, camera devices located within a givengeographical radius at a given time frame and with cameras pointing in adesired orientation may be first identified 802. For example, if theobject of interest is an unrecognized face detected inside a vehicleparked in a parking lot, camera devices from other vehicles in the sameparking lot at the same time and directed at the vehicle that was brokeninto at the right time may be identified 802. Optionally, once therelevant camera devices are identified 802, a request for an imagesearch query with the query for the object of interest is sent 803. Thecamera devices receiving this request can search their buffered videodata with the image search query provided to determine if there is amatch. In one embodiment, the feature vectors for the object of interestand compared with feature vectors for potentially relevant objectsidentified in the video data to determine if there is a match. Forexample, if the object of interest is a human face, a face featurevector is provided with the query and camera devices can use imageprocessing to identify faces in the video data, extract feature vectorsfor the identified faces, and compare to the face feature vector of thedesired face. Optionally, the search request may provide a time frame ofinterest to further reduce the buffered video objects that need to beanalyzed to respond to the request.

In one embodiment, the cloud system 103 monitors the user objectselection process to identify selection of the same object by multipleusers. Upon determining that multiple users have selected the sameobject, generating the same or a substantially similar image query, thesystem may, for example, notify the users via news pane 401 c of otherusers with similar interests. The object query may be additionallymatched based on location (e.g., same object identified by users withina maximum distance), time, and/or event type.

Responses to the search request are received 804. If no matches arefound 805, the sharing request process ends 806. For example, if thesearch request was initiated by a user, the user may be notified that nomatching video clips were found. If matching video clips are found 805,an authorization request is sent 807 to the user of the camera deviceresponding with a match. As discussed above with reference to FIG. 4a-c, the clips generated from camera devices of the user may be listedunder the clips pane 401 a. Thus, the user may access clips generated705 from a client device 101, an auxiliary camera 106, a mobile device104, without further authorization requirement. For example, in oneembodiment, when the camera devices with video clips matching the sameevent, such as a break-in, are registered to the same user account, theuser may directly access the shared video clips from one or more homeauxiliary cameras 106 that captured the same break-in as thedash-mounted client device 101 from different vantage points. Thus, forexample, a user may be able to provide related video clips to theauthorities showing a perpetrator's face (from an IN-camera device), a“get-away” vehicle from an auxiliary home camera device located in acarport, and a license plate for the get-away vehicle from a drivewayauxiliary camera device. The video clips for the break-in event could beautomatically generated and associated as “related” clips from multiplecamera devices integrated by the system according to one embodiment ofthe invention.

In one embodiment, the authorization request may include a dynamicallygenerated video clip for the user to review in determining whether toauthorize the sharing of the video clip with other users. In oneembodiment, the authorization request may be fulfilled automaticallybased on pre-authorization recorded during sign-on, e.g., for neighbors,for specific cameras, or the like. Alternatively, the authorizationrequest is fulfilled by other users. For example, a playlist or manifestfile may be included with the request allowing the authorizing user toplayback the relevant video objects with the matching object. As notedabove, the video objects can be accessed directly from the camera devicebuffer, for example via the Internet or a direct network connection(e.g., Wi-Fi) between a mobile device and the camera device. Inaddition, if the video objects are encrypted, the authorization requestmay include a user identification request to obtain the requiredencryption key, such as for example, a biometric identification (e.g.,face recognition, fingerprint, or the like). With the appropriateencryption key, the video objects are decrypted and playback to the userto obtain authorization for sharing. In addition, in one embodiment, theuser may optionally request the system to obfuscate identified objectsin the shared video clip. For example, any human faces, license plates,address numbers, and/or any other identifiable objects selected by theuser may be automatically blurred in the video data to protect privacyupon user request. Alternatively, the system may by default obfuscateidentifiable objects unless otherwise requested and/or authorized bysystem users.

If sharing authorization 808 cannot be obtained, the sharing requestterminates 806, by for example notifying a user requesting the sharingthat no clips are available. If authorization is obtained 808, for everymatching video clip for which authorization is obtained is shared 809with other users. For example, in one embodiment, if the sharing requestwas initiated by a user, the requesting user is notified of theavailability of matching video clips. For example, the mobile app of therequesting user's mobile device 104 receives a notification from cloudsystem 103 and provide the notification to the user via the mobile appuser interface. If the sharing request was automatically generated by acamera device of a user, for example from an auto-tagging event, themobile app in the mobile device 104 of the user receives a notificationof the availability of other video clips relevant to the user. Themobile app may then display information regarding the available videoclips on the news pane 401 c. Optionally, the mobile app may directlylink the available video clips to the event-generated clips on the clipspane 401 a. Any video clips for encrypted video data would have beendecrypted through the authorization process and thus become shared videoclips in unencrypted form.

In one embodiment, the video sharing request process is used to generatea virtual network of distributed cameras recording video for an event ofinterest. For example, the video clip generation process may include alive-stream playlist or manifest file dynamically generated and updatedwith additional clips being recorded for the given event. Using thisapproach, the system may generate a set of associated video clips for agiven event, such as for example, a break-in, car accident, or the like,captured from cameras in the dynamically generated virtual network toprovide views from different angles, vantage points, and/or wider ornarrower views. For example, in one embodiment, interspersed stillimages from video captured by multiple camera devices may be used forlicense plate recognition purposes where video from a single camera isinsufficient. In one embodiment, in addition to the license plate or ifunable to recognize the license plate the color and make and model ofthe vehicle may be determined based on classifier-based imagerecognition techniques. The video sharing process of FIG. 8 iscontinuously run adding and removing camera devices to the virtualnetwork as necessary. For example, if the event is a car accident on afreeway, vehicle-mounted client devices 101 with the proper orientation(i.e., facing the accident) are dynamically added and removed from thevirtual network based on their location, time, and orientation match,i.e., near the accident and facing it, and failure to match, afterpassing the accident location.

According to another aspect of the disclosure, the video data generatedby the camera devices in the system may be uniquely identifiable andverifiable to be authentic and unmodified. Now referring to FIG. 9, anexemplary method for verifying authenticity of video data according toone embodiment is described. In this embodiment, both video data objectsand video clips may be authenticated. In alternative embodiments, eithervideo data objects or video clips can be separately authenticated, oronly one or the other may optionally be authenticated without departingfrom the teachings of this disclosure. The method begins with anauthentication request 900. For example, a request to authenticate avideo generated by a camera device associated with cloud system 103 maybe submitted to a cloud server 102, via for example, a Web-basedinterface 105 to a system website. In one embodiment, a file is providedwith the request. In one embodiment, a determination 901 is made as towhether the request is for a video clip or for a video data object, suchas video file. This step may be omitted in alternative embodiments. Thedetermination may be made, for example, based on the type of filesubmitted (e.g., a playlist or manifest file or a video data file),based on the GUID associated with the file (e.g., a GUID for a videoclip or a GUID for a video data object), or based on other criteria,such as for example, an explicit input provided in the request.

In one embodiment, if the request is determined 901 to be for a videoclip, the playlist or manifest file for the video clip is accessed toretrieve 902 the list of video data objects or files in the video clip.The first video data object is selected 903. In one embodiment, if therequest is determined 901 to be for a video data object, or if it is fora video clip and the first video data object has been selected 903, themetadata record associated with the video clip is retrieved 904. Forexample, in one embodiment, the GUID for the video data object is usedto access a repository of metadata records associated with video dataobjects captured by camera devices associated with the cloud-basedsystem 103. As described above, every camera device sends signedmessages to the system including the metadata and a hash of the videodata object for every data object recorded. In one embodiment, ametadata record includes the metadata and the hash of the video data andmay be indexed by the associated GUID.

The stored hash of the video data object corresponding to the GUID isthen compared 905 to a one-way hash of the video data object for whichauthentication is requested. In one embodiment, the authenticationrequest includes the video data object. In that embodiment, the videodata object is hashed using the same one-way hashing function used bythe camera devices of the system. In an alternative embodiment, anetwork address for the video data object is provided in video clipfile. In such an embodiment, the video data object is retrieved, forexample at step 903 (or step 909 for subsequent video data objects), andit is hashed as described above. If the system is implemented based onhashing of the video data along with the metadata, the metadataretrieved 904 (if not part of the request) is used in the hashingfunction for the video data object being verified. The hashing functionmay be applied on a server, such as server 102, or may be performed on aclient, such as Web-based client 105, and provided to the authenticationsystem, for example along with the request.

In one embodiment, the result of the hash comparison 905 is used tooutput 906 a verification for the video data object. The verificationoutput may, for example, provide a positive or negative result,indicating whether the video data is authentic or whether it has beenmodified. In one embodiment, the verification output may also includerelevant metadata associated with the video data object, such as time,location, orientation, and the like. In one embodiment, if the videodata object verified is not part of a video clip 907, the verificationprocess concludes 908.

However, if the video data object is part of a video clip 907, theprocess continues to step 909. At step 909, if the video data objectthat was verified was the first video data object in a video clip 909,the next video data object is selected 910 and the process repeats fromstep 904 for verification of the second video data object in the videoclip. If the video data object is not the first in a video clip, a timeanalysis 911 is performed next. In one embodiment, as described above,the metadata for a video data object includes time information toidentify when the video data was captured. For example, in oneembodiment, atomic time from a 4G/LTE service provider is used to createa time stamp of the beginning of the video data object and either aduration or end stamp to indicate its end. In one embodiment, this timeinformation is provided with the video object verification output 906,and used for time analysis 911. For example, the ending time of thefirst video data object in a clip is compared to the beginning time forthe second video data object of the clip to determine if there is a gap.A gap in the time sequence between consecutive video data objects of agiven video clip may for example indicate some editing to the videoclip.

In one embodiment, if there are additional video data objects to beverified in a video clip 912, the process moves to step 910 and repeatsthrough the time analysis step 911 for every video data object. Once allthe video data objects in a video clip are verified 912, a video clipverification output is provided 913. For example, if all the video dataobjects in the clip were positively verified and the time analysis didnot identify any gaps, a positive authentication for the video clip maybe output 913. Optionally, the output may for example, includeadditional information regarding the video clip, such as, for example,time, duration, location, camera device used, user, or the like.Conversely, if any of the video clips cannot be authenticated, e.g., thehashes do not match, or a gap in the video clip timeline is found atstep 911, a negative result is output 913. The output may for example,include reasons for the negative result in addition to or in place ofany of the information provided for a positive result. For example, inone embodiment, a video clip consisting of 15 two-second video filesgenerated upon detection of a car crash by a client device 101 could beuniquely verified as authentic by cloud system 103 using the approachdescribed above.

According to another aspect of the disclosure, a process for setting upa camera device, such as a client device 101, is provided. Referring toFIG. 10, a method for setting up a camera device for operation in thesystem according to one embodiment is described. In one embodiment,camera devices, such as client device 101, include cellular connectivitythat is operational as soon as the device is powered up. Cellularconnectivity provides a data connection 107/108 between the cameradevice and the cloud system 103 that can be used during the set-upprocess. When the camera device is powered up, the set-up process begins1000. While the following set up steps are provided in order, noparticular order is required for these steps. For example, in oneembodiment, a user set up step 1001 is performed. In one embodiment, theuser set up step 1001 allows the camera device to recognize the user.For example, in one embodiment, a client device 101 providesinstructions to a user to pose in different orientations while facingone of the cameras to record different angles of the user's face.Optionally, a similar process may be used to recognize other userbiometrics, including for example, fingerprints, voice, and irises. Forexample, a touch sensor may be used to record a series of images of auser's fingerprint. Voice recognition software may be trained by havingthe user repeat pre-defined commands, statements, or sentences one ormore times. In one embodiment, a user's iris is recorded from multipleangles to derive a biometric optical signature. Other embodiments mayinclude a combination of these biometrics identifications and mayfurther include others.

The user's biometric signature or signatures are stored in the cameradevice. In one embodiment, a cryptographic key is also generated basedon a random input and stored in association with the biometricidentification of the user. Optionally, if more than one user isrequired, for example for a vehicle with multiple possible drivers, theuser set up process 1001 is repeated for each user.

Referring back to FIG. 10, another set up step involves the associationof the camera device with one or more mobile devices 104. It should benoted that mobile device 104 may itself be a camera device, and thussome of the set-up steps, such as user set up step 1001 may beapplicable. Mobile device 104 includes a mobile app installed on thedevice as described above with reference to FIG. 4a-4c . In oneembodiment, mobile device 104 and camera device (e.g., client device101) include a short range wireless modules, such as Bluetoothtransceivers. As is known in the art, short range wireless modules maytransmit a unique ID that can be received by other short range wirelessmodules as a for of identification of devices in forming a piconet orotherwise pairing with each other. For example, Bluetooth transceiverscan provide a unique 12-digit hexadecimal address (“BD ADDR”) foridentification and pairing.

In one embodiment, a user may prompt the camera device to pair with theuser's mobile device 104. For example, in one embodiment, the user mayutter a voice pairing command, provide a pairing command through atouchscreen, or through any other user input device available in thecamera device. In one embodiment, the pairing process involves aBluetooth paring process. In another embodiment, the camera devicedisplays a unique pattern that is captured by the mobile device and sentback to the camera device via the connection to the could system 103.For example, camera device may display a randomly generated alphanumericcode, a QR code, a series of black and white screens in a random order,or some other random output. The random output is captured or enteredinto the mobile device by the mobile app and transmitted via a securedInternet connection to cloud system 103 along with a unique identifierof the mobile device, such as, for example a Bluetooth address, a MACaddress, or the like. The random output and the mobile device input arecompared. If they match, the camera device authenticates the mobiledevice unique identifier (e.g., Bluetooth address or MAC address) andfrom that point on is associated with the mobile device. In analternative embodiment, instead of comparing the output of the clientdevice with the input captured by the mobile device, both devicesgenerate an output that is compared at the server. For example, eachdevice uses a camera to perform face recognition of the user during theset-up process and their face recognition results are sent to the serverfor comparison to match the same user.

In one embodiment, a QR code is displayed on the display of the clientdevice 101. The QR code encodes a device ID for the client device 101and an encryption key (or seed for generation of an encryption key) forcommunicating with the client device 101. The mobile app on the mobiledevice 104 captures and interprets the QR code to obtain the device IDand encryption key. The device ID may for example include a telephonenumber, email address, or other means for electronic messaging with theclient device 101. Using the encryption key, the mobile device 104 cansend encrypted communications to the client device 101 as furtherdescribed below to associate the mobile device with the client device,including for example, sending to the client device 101 a uniqueidentifier for the mobile device 104, for example, telephone number,email address, Bluetooth address, MAC address, or the like. Whiledescribed with the client device 101 being the device that displays theQR code, the same approach may be used with the mobile device 104displaying the QR code and the client device 101 initiating theencrypted messaging using the encryption key provided by the mobiledevice 104.

Other “shared secret” approaches may be used for mobile deviceassociation 1002, include for example, a series of instructions to causethe user to move the mobile device while the mobile app records theoutputs of one or more mobile device sensors to be matched with theprovided instructions. For example, the user may raise or lower thedevice, shake the device, etc. in a random series causing accelerometerand/or gyroscope changes that match the requested motions. The series ofsensor-detected motions can be provided via Internet connection formatching with the camera device instructions for association.Alternatively, in one embodiment, a user may provide a telephone numberfor the mobile device during a registration process, for example throughthe mobile device app. For the mobile device association step 1002,camera device may display a device ID on its screen. The user inputs thedevice ID on the mobile app and it is transmitted to the cloud system103. The cloud system identifies the device ID and sends a message tothe camera device 101/106 via Internet connection 107/108 including thetelephone number for mobile device 104. The camera device sends a textmessage to mobile device 104 with a random code. The user inputs therandom code via the mobile app for verification by cloud system 103 orcamera device 101/106. If the random code matches the texted code, themobile device is authenticated. Once the camera device and the mobiledevice are associated 1002, the camera device can trust the mobiledevice for subsequent interactions, based on a unique ID for the mobiledevice (e.g., Bluetooth address, MAC address, or the like).

According to another aspect of disclosure, in one embodiment, the set-upprocess optionally includes the step of provisioning the mobile device104 with a mobile app. FIG. 11 provides an exemplary flow diagram for aninitial set-up process according to one embodiment. As described above,camera device 101/108 includes a wireless cellular connection to theInternet and is configured to communicate with cloud system 103 out ofthe box. When the camera device is first turned on, the screen displaysa QR code 1101. A mobile device can use one of its existing apps tocapture the QR code with its camera and interpret the code 1102. In thisembodiment, the QR code provides a link or URL to a web-server, forexample in cloud system 103. The link or URL may include an IP addressor a domain (e.g., www.owl.us) and a set of parameters encoded thereinas is known in the art. One of the parameters may include, for example,a unique ID for the camera device 101/108 being set up, such as forexample, a mobile device number, a telephone number, a serial number, orthe like. Optionally, the link parameters may also include a randomlygenerated number that is different for different times the set-upprocess is run. Alternatively, instead of displaying a QR code, the sameprocess may be performed providing the link and parameters inalternative forms, including for example, by displaying them on thescreen as text/image, encoding them in an audio signal, transmittingthem via short range communication (IR, AirDrop, Bluetooth, etc.) or thelike.

Upon interpreting the QR code, the mobile device uses its existingsoftware (e.g., a web browser) to send 1103 an HTTP request to the webserver identified through the link or

OWL 0005 URL and including the parameters encoded into the link. Thecloud system 103 receives the request and creates 1104 a record for therequest, including the link-encoded parameters and additional metadataand network information derived from the HTTP requesting process,including information for uniquely identifying the mobile device 104(e.g., combination of HTTP heather metadata, TCP/IP header information,or the like). In addition, cloud system 103 redirects 1105 the mobiledevice to a location from where the appropriate mobile app may beobtained. For example, cloud system 103, using, for example, the“User-Agent” data from the HTTP request and/or the unique device ID forthe camera device 101/108, redirects the mobile device 104 to either theApple App Store when the User-Agent indicates the mobile device to be aniOS device or to the Google Play Store if the mobile device isdetermined to be an Android-based device or alternatively, to otherservers capable of providing the mobile app to the mobile device over anetwork. Similarly, the cloud system 103 may include parameters in theredirection link to the appropriate version of the mobile app determinedusing the device ID of the camera device 101/108.

Once redirected, the mobile device 104 obtains 1106 the proper mobileapp, e.g., the app for interaction with camera device 101/108 and cloudsystem 103. After the downloading and installation of the mobile app onmobile device, when executed, the mobile app contacts the cloud system103 to access 1107 the record previously generated at step 1104. Forexample, the mobile app may derive a unique ID for the mobile device 104using the same parameters, metadata, or other information available fromthe mobile device 104 when making an HTTP request like the one made atstep 1103. In one embodiment, a time limit (e.g., 2-15 minutes) may beused between the HTTP request step 1103 and the record access step 1107to facilitate the mobile device 104 identification. Cloud system 103determines that the same mobile device 104 is accessing the system basedon that information and provides 1108 access to the previously generatedrecord and any other additional set up parameters that may be necessaryto complete the set-up process. For example, if provided, the randomlygenerated number may be provided as a “shared secret” for the deviceassociation process described above. Alternatively, encryptioninformation and/or messaging information for the camera device may beprovided.

Referring back to FIG. 10, another aspect of the disclosure involvessetting up a direct connection between a camera device 101/108 and amobile device 104. In one embodiment, camera device 101/108 includeswireless local area network connectivity. In this embodiment, forexample, a client device 101 may optionally operate as an access point(AP) for a local area network, such as Wi-Fi network. The mobile device104 can establish a connection 109 to the client device 101 as a Wi-Fistation (STA). While a specific wireless local area network connectionis described, it is understood that the present invention can be appliedto a wide variety of wireless connection modes, such as, for example,Peer-to-Peer connections (e.g., “Wi-Fi Direct, ad hoc network, or thelike). The camera device can use the MAC address authenticated through amobile device association process 1002 to determine whether theassociated mobile device is the one making the connection. The directcamera device to mobile device connection 109 may then be used totransfer settings, video data objects, video clips, biometricsignatures, and the like, in a secured way between the devices.

As those in the art will understand, a number of variations may be madein the disclosed embodiments, all without departing from the scope ofthe invention, which is defined solely by the appended claims. It shouldbe noted that although the features and elements are described inparticular combinations, each feature or element can be used alonewithout the other features and elements or in various combinations withor without other features and elements. The methods or flow chartsprovided may be implemented in a computer program, software, or firmwaretangibly embodied in a computer-readable storage medium for execution bya general-purpose computer or a processor.

Examples of computer-readable storage mediums include a read only memory(ROM), a random-access memory (RAM), a register, cache memory,semiconductor memory devices, magnetic media such as internal hard disksand removable disks, magneto-optical media, and optical media such asCD-ROM disks.

Suitable processors include, by way of example, a general-purposeprocessor, a special purpose processor, a conventional processor, adigital signal processor (DSP), a plurality of microprocessors, one ormore microprocessors in association with a DSP core, a controller, amicrocontroller, Application Specific Integrated Circuits (ASICs), FieldProgrammable Gate Arrays (FPGAs) circuits, any other type of integratedcircuit (IC), and/or a state machine.

One or more processors in association with software in a computer-basedsystem may be used to implement methods of video data collection,cloud-based data collection and analysis of event-based data, generatingevent-based video clips, sharing event-based video, verifyingauthenticity of event-based video data files, and setting up clientdevices according to various embodiments, as well as data models forcapturing metadata associated with a given video data object or file orfor capturing metadata associated with a given event-based video clipaccording to various embodiments, all of which improves the operation ofthe processor and its interactions with other components of acomputer-based system. The camera devices according to variousembodiments may be used in conjunction with modules, implemented inhardware and/or software, such as a cameras, a video camera module, avideophone, a speakerphone, a vibration device, a speaker, a microphone,a television transceiver, a hands free headset, a keyboard, a Bluetoothmodule, a frequency modulated (FM) radio unit, a liquid crystal display(LCD) display unit, an organic light-emitting diode (OLED) display unit,a digital music player, a media player, a video game player module, anInternet browser, and/or any wireless local area network (WLAN) module,or the like.

What is claimed is:
 1. A method for managing video buffering in a localbuffer memory of a video capturing device comprising one or more videocameras for recording video footage, the method comprising: receivinginput from a plurality of sources, the input identifying featuresindicative of an operational mode of the video capturing device;determining, based on the identified features of the received input, anoperational mode for the video footage recorded while in the determinedoperational mode; setting video recording parameters for at least one ofthe one or more video cameras based on the determined operational mode,the video recording parameters causing an increase in the number ofbytes per unit of time of video data stored in the local buffer memoryfrom at least of the one or more video cameras when the operational modecorresponds to video footage of an event of interest.
 2. The method ofclaim 1, wherein the input from the plurality of sources comprise atleast one of motion, location, CAN bus data, face recognition data,object recognition data, Bluetooth data, or WiFi data.
 3. The method ofclaim 1, wherein the input from the plurality of sources comprises facerecognition data and further wherein the face recognition datacorresponds to the event of interest comprising detection of a humanface.
 4. The method of claim 1, wherein the input from the plurality ofsources comprises object recognition data and further wherein the objectrecognition data correspond to the event of interest comprisingdetection of emergency vehicle lights.
 5. The method of claim 1, whereinthe operational mode comprises at least one of a driving mode, a parkedmode, or an armed mode.
 6. The method of claim 1, wherein the videorecording parameters comprise a video quality parameter and a frame persecond parameter.
 7. The method of claim 1, further comprising:determining whether the determined operational mode requires additionalactions; and performing the additional actions.
 8. The method of claim5, wherein the additional actions include further setting the set videorecording parameters to further increase the number of bytes per unit oftime of video data stored in the local buffer memory in order to writeover video data stored beyond a preset limit of time.
 9. The method ofclaim 5, wherein the additional actions include sending a notificationto a user indicating that video data being stored in the local buffermemory is likely to be stored over previously recorded video data beforea preset limit of time.
 10. The method of claim 5, wherein thedetermining whether the determined operational mode requires additionalactions comprises a learning function that learns a history ofoperational mode determinations and further wherein the performing ofthe additional action comprises applying the learned history to optimizethe storing of video data in the buffer memory.
 11. The method of claim1, wherein the input further comprises data regarding a historical usageof the local buffer memory and further wherein the determining of theoperational mode is based at least in part on the historical usage data.12. A system for managing video buffering in a video capturing devicecomprising: one or more video cameras for recording video footage; alocal buffer memory; a plurality of sensors; a processor, the processorconfigured to receive input from the plurality of sensors, the inputidentifying features indicative of an operational mode of the videocapturing device, the processor further configured to determine, basedon the identified features of the input, an operational modecorresponding to video footage to be recorded by the video capturingdevice, and further configured to set video recording parameters for theone or more video cameras based on the operational mode, the videorecording parameters having an associated number of bytes per unit oftime of video data to be stored in the local buffer memory.
 13. Thesystem of claim 12, wherein the input from the plurality of sourcescomprise at least one of motion, location, CAN bus data, facerecognition data, object recognition data, Bluetooth data, or WiFi data.14. The system of claim 12, wherein the input from the plurality ofsources comprises face recognition data and further wherein the facerecognition data corresponds to the event of interest comprisingdetection of a human face.
 15. The system of claim 12, wherein the inputfrom the plurality of sources comprises object recognition data andfurther wherein the object recognition data correspond to the event ofinterest comprising detection of emergency vehicle lights.
 16. Thesystem of claim 12, wherein the plurality of sensors include at leastone of a motion sensor, a location sensor, a light sensor, a gyroscope,or a temperature sensor.
 17. The system of claim 12, wherein theoperational mode comprises at least one of a driving mode, a parkedmode, or an armed mode.
 18. The system of claim 12, wherein the videorecording parameters comprise a video quality parameter and a frame persecond parameter.
 19. The system of claim 12, wherein the plurality ofsensors include at least one vehicle sensor communicating data via a CANbus.
 20. A system comprising: one or more video cameras; a local buffermemory for storing video data from the one or more video cameras; atleast one processor; and memory storing instructions that, when executedby the at least one processor, configure the system to: receive inputfrom a plurality of sources, the input identifying features indicativeof an operational mode; determine, based on the identified features ofthe received input, an operational mode corresponding to a video footageto be recorded by the one or more video cameras; set video recordingparameters for at least one of the one or more video cameras based onthe determined operational mode, the video recording parameters causingan increase in the number of bytes per unit of time of video data storedin the local buffer memory from at least of the one or more videocameras when the operational mode corresponds to video footage of anevent of interest.
 21. The system of claim 16, wherein the input fromthe plurality of sources comprise at least one of motion, location, CANbus data, face recognition data, object recognition data, Bluetoothdata, or WiFi data.
 22. The system of claim 20, wherein the input fromthe plurality of sources comprises face recognition data and furtherwherein the face recognition data corresponds to the event of interestcomprising detection of a human face.
 23. The system of claim 20,wherein the input from the plurality of sources comprises objectrecognition data and further wherein the object recognition datacorrespond to the event of interest comprising detection of emergencyvehicle lights.
 24. The system of claim 20, wherein the operational modecomprises at least one of a driving mode, a parked mode, or an armedmode.
 25. The system of claim 20, wherein the video recording parameterscomprise a video quality parameter and a frame per second parameter. 26.The system of claim 20, the memory storing additional instructions that,when executed by the at least one processor, further configure thesystem to: determine whether the operational mode requires additionalactions; and perform the additional actions.
 27. The system of claim 26,wherein the additional actions include further setting the set videorecording parameters to further increase the number of bytes per unit oftime of video data stored in the local buffer memory in order to writeover video data stored beyond a preset limit of time.
 28. The system ofclaim 26, wherein the additional actions include sending a notificationto a user indicating that video data being stored in the local buffermemory is likely to be stored over previously recorded video data beforea preset limit of time.
 29. The system of claim 26, wherein theadditional instructions stored in the memory that, when executed by theat least one processor, further configure the system to determinewhether the operational mode requires additional actions, furtherconfigure the system to learn a history of operational modedeterminations, and wherein the additional instructions that configurethe system to perform the additional actions, further configure thesystem to apply the learned history to optimize the storing of videodata in the buffer memory.